Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-063.TXT

Text File | 1992-06-03 | 41.8 KB | 1,152 lines

C.S.M.P. Digest             Thu, 30 Apr 92       Volume 1 : Issue 63

Today's Topics:

    print architecture (was Re: Patching a trap for print jobs...)
    How to Drop & Launch??
    Finder Selection anyone?
    ML for Mac
    Lost ETO
    GnuPlot on the mac --  UPDATE
    WDEFs in System File:Do They Do Anything???


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (JohnC)
Subject: print architecture (was Re: Patching a trap for print jobs...)
Date: 11 Mar 92 16:33:37 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (David Casseres) writes:
>The original idea behind the separation of low-level and high-level printing
>interfaces was that on a 128K Mac there might not be enough space to load up
>the PDEF of the high-level interface.  In that desperate case the app could
>still print using the low-level DRVR interface, since it was very small.  I
>don't know of any major app that actually took advantage of this, though.

This is something that has bugged me for a long time.  Why why why wasn't
the printing glue implemented as a _package_?  Doing so would have still
allowed the code to be unloaded in low-memory situations, but there would
have been a TRAP all along, instead of the insanity of a static library!


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (David Casseres)
Date: 20 Mar 92 18:36:54 GMT
Organization: Apple Computer Inc.

In article <[e-mail]>, [e-mail]
(JohnC) writes:
>
> In article <[e-mail]> [e-mail] (David Casseres) writes:

> This is something that has bugged me for a long time.  Why why why wasn't
> the printing glue implemented as a _package_?  Doing so would have still
> allowed the code to be unloaded in low-memory situations, but there would
> have been a TRAP all along, instead of the insanity of a static library!

Well, I will give a carefully restricted answer and see if anyone argues:  there
was no good reason, and a number of bad ones.

- --

David Casseres
Exclaimer: Wow!

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 20 Mar 92 19:36:44 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (David Casseres) writes:
>In article <[e-mail]>, [e-mail]
>(JohnC) writes:
>> This is something that has bugged me for a long time.  Why why why wasn't
>> the printing glue implemented as a _package_?  Doing so would have still
>> allowed the code to be unloaded in low-memory situations, but there would
>> have been a TRAP all along, instead of the insanity of a static library!
>
>Well, I will give a carefully restricted answer and see if anyone argues:
>there was no good reason, and a number of bad ones.

Would you mind enumerating said bad reasons?  I'm truly interested, since
I'm sure the architects of the Printing Manager were not stupid people.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (David Casseres)
Date: 29 Mar 92 22:04:43 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(JohnC) writes:

[I wrote]
> >Well, I will give a carefully restricted answer and see if anyone argues:
> >there was no good reason, and a number of bad ones. [for not implementing
the Printing Manager via a trap]

> Would you mind enumerating said bad reasons?  I'm truly interested, since
> I'm sure the architects of the Printing Manager were not stupid people.

They weren't.  But it was not they who decided not to allocate a trap for
printing.

- --
David Casseres
Exclaimer: Wow!

---------------------------

Subject: How to Drop & Launch??
From: [e-mail] (Steve Trutiak)
Date: Thu, 12 Mar 1992 22:16:38 GMT
Organization: Abekas Video Systems Inc., Redwood City, California.

Can anyone explain how to make system 7 applications launch when you drop
file icons onto their icons?

Thank You

Stephen Trutiak


+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 27 Mar 92 22:18:58 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Steve Trutiak) writes:
>
> Can anyone explain how to make system 7 applications launch when you drop
> file icons onto their icons?

It just happens.  ;)

Actually, your application must contain a FREF for the file type you want
to be dropped on your app.  You need a FREF for each file type or one
of type **** to drop anything.  You also need to rebuild the desktop after
changing or adding a FREF.

If it still doesn't work your app isn't checking for files.  See the Segment
Loader (pre-7) or Apple Events (post-7) chapters for more info.

Jon

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 27 Mar 92 22:18:58 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Steve Trutiak) writes:
>
> Can anyone explain how to make system 7 applications launch when you drop
> file icons onto their icons?

It just happens.  ;)

Actually, your application must contain a FREF for the file type you want
to be dropped on your app.  You need a FREF for each file type or one
of type **** to drop anything.  You also need to rebuild the desktop after
changing or adding a FREF.

If it still doesn't work your app isn't checking for files.  See the Segment
Loader (pre-7) or Apple Events (post-7) chapters for more info.

Jon

---------------------------

From: [e-mail] (Dan Walkowski)
Subject: Finder Selection anyone?
Organization: University of Illinois at Urbana
Date: Sat, 14 Mar 1992 23:56:41 GMT

Has _anyone_ managed to figure out how to determine the Finder selection?

Millions of frustrated Mac programmers (myself included) would praise you
and probably even erect monuments if you would share the knowledge.

Dan Walkowski
- --
Dan Walkowski
Univ. of Illinois
[e-mail]

+++++++++++++++++++++++++++

From: caligula!edw (Edwin Howell Watkeys III)
Date: Sun, 15 Mar 92 01:15:52 EST
Organization: Drexel University Guerrilla Networking Project


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Dan Walkowski) writes:
> Has _anyone_ managed to figure out how to determine the Finder selection?
>
> Millions of frustrated Mac programmers (myself included) would praise you
> and probably even erect monuments if you would share the knowledge.
>
Even *if* you could figure out a way, I read in the FinderEvents Stack that
it would probably change, and you'd need to change it as soon as the next
Finder came out... However, the FinderEvents Stack may (I forget) tell you
how to do it, and if it does, it says, THIS WON'T WORK DOWN THE ROAD!!!

Ed

- ---------
Ed Watkeys                         "...if you wish to strive for peace of
phlpa!caligula![e-mail]   soul and pleasure, then believe; if
Drexel University (Comp Sci)        you wish to be a devotee of truth,
Guerrilla Networking Project        then inquire...." -- Nietzsche

+++++++++++++++++++++++++++

From: [e-mail] (Dan Walkowski)
Organization: University of Illinois at Urbana
Date: Sun, 15 Mar 1992 19:08:42 GMT

caligula!edw (Edwin Howell Watkeys III) writes:
>Even *if* you could figure out a way, I read in the FinderEvents Stack that
>it would probably change, and you'd need to change it as soon as the next
>Finder came out... However, the FinderEvents Stack may (I forget) tell you
>how to do it, and if it does, it says, THIS WON'T WORK DOWN THE ROAD!!!

>Ed


The Finder Events stack does not tell you how.  I realize that it will change
in future versions.

I still want to know.

Dan
- --
Dan Walkowski
Univ. of Illinois
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Mon, 16 Mar 1992 18:21:56 GMT

Dan -

I know of someone who has...a few people actually...but it is a well
kept secret by the few who were able to figure it out :) Why should
they give it away when people are willing to pay for it?

<joe>





- --
<--------------------------------------------------->
 joe zobkiw                     [e-mail]
 mac.synthesis.MIDI.development.C.asm.communications
>---------------------------------------------------<

+++++++++++++++++++++++++++

From: [e-mail] (Dan Walkowski)
Organization: University of Illinois at Urbana
Date: Mon, 16 Mar 1992 20:30:31 GMT

[e-mail] (Joe Zobkiw) writes:

>Dan -

>I know of someone who has...a few people actually...but it is a well
>kept secret by the few who were able to figure it out :) Why should
>they give it away when people are willing to pay for it?

><joe>


Now what kind of attitude is that?  Is this a forum where we discuss our
various questions and tricky mac programming solutions, or some kind of
secret club run by 12-year olds?

I'm perfectly happy to share any of the tricks I've learned with whomever
asks.

Dan
- --
Dan Walkowski
Univ. of Illinois
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Ross Brown)
Organization: Bell-Northern Research
Date: Sun, 15 Mar 92 23:35:30 GMT

In article <[e-mail]> caligula!edw (Edwin Howell Watkeys
III) writes:
>
>In article <[e-mail]> (comp.sys.mac.programmer),
[e-mail] (Dan Walkowski) writes:
>> Has _anyone_ managed to figure out how to determine the Finder selection?
>>
>> Millions of frustrated Mac programmers (myself included) would praise you
>> and probably even erect monuments if you would share the knowledge.
>>
>Even *if* you could figure out a way, I read in the FinderEvents Stack that
>it would probably change, and you'd need to change it as soon as the next
>Finder came out... However, the FinderEvents Stack may (I forget) tell you
>how to do it, and if it does, it says, THIS WON'T WORK DOWN THE ROAD!!!
>
>Ed
>
>---------
>Ed Watkeys                         "...if you wish to strive for peace of
>phlpa!caligula![e-mail]   soul and pleasure, then believe; if
>Drexel University (Comp Sci)        you wish to be a devotee of truth,
>Guerrilla Networking Project        then inquire...." -- Nietzsche
>

I'll quote it for those who don't have the FinderEvents stack (by Jon Pugh)...

A lot of people want the Finder to do some real basic things that it just
doesn't do right now. This explains a few of the limitations that the Finder
operates under.

The most notable of these is the desire to get the current Finder selection.
You can't. Yes, I know some people do, but they figured out how and know that
it will break when the Finder gets changed. They have chosen to do that work
and take that risk. You haven't. You want it handed to you. You can't have it
that way. If you really want to know then hop into Macsbug and find out. Save
your notes because you will have to do it again when the Finder changes.
Hopefully this situation will change when the Finder supports all Apple Events.

Ross Brown
Bell-Northern Research Ltd.
Ottawa, Ontario, Canada
[e-mail]
Opinions expressed do not necessarily represent those of BNR.

+++++++++++++++++++++++++++

From: [e-mail] (Nobukazu Toge)
Date: 17 Mar 92 00:45:43 GMT
Organization: Stanford Linear Accelerator Center

Dan -

I don't know the answer on how to do that, but I believe that people at
Salient Software know that, because their DiskDoubler INIT does exactly
part of what you would like to achieve.  I believe that the fact they
know this, by itself, is no secret -- they got a published product!

Yes, I tried disassembling their software... No, nothing made sense to me.
Yes, probably you can ask... No, I don't believe they would give away
the info.

Like the AppleEvent stack says, in principle, you should be able to figure
it out by tracing with MacsBug etc through how the Finder launches an app
etc.  I understand that Finder (Sys 7) has been written with C++, so the
job has to be very, very painful, unless you are extremely clever
(I'm not).

Cheers,

- - Nobu Toge (Stanford Linear Accelerator Center)
* My employer SLAC, Stanford University or U.S. DoE are not responsible
* for this posting.  My opinion is only mine, unless someone else shares
* it.

+++++++++++++++++++++++++++

From: [e-mail] (David Castell)
Date: 17 Mar 92 17:22:43 GMT
Organization: Computer Systems Group

In article <[e-mail]>, Nobukazu Toge <[e-mail]> writes:
>
> Dan -
>
> I don't know the answer on how to do that, but I believe that people at
> Salient Software know that, because their DiskDoubler INIT does exactly
> part of what you would like to achieve.  I believe that the fact they
> know this, by itself, is no secret -- they got a published product!
>
> Yes, I tried disassembling their software... No, nothing made sense to me.
> Yes, probably you can ask... No, I don't believe they would give away
> the info.
>
> Like the AppleEvent stack says, in principle, you should be able to figure
> it out by tracing with MacsBug etc through how the Finder launches an app
> etc.  I understand that Finder (Sys 7) has been written with C++, so the
> job has to be very, very painful, unless you are extremely clever
> (I'm not).
>
> Cheers,
>
> - Nobu Toge (Stanford Linear Accelerator Center)
> * My employer SLAC, Stanford University or U.S. DoE are not responsible
> * for this posting.  My opinion is only mine, unless someone else shares
> * it.
>
I traced through the DiskDoubler stuff too, and I could tell you what they
do (if I can find my notes around here somewhere), but it only lets you get
the selection, not set it.  BTW, I have seen someone else mention this method
on this newsgroup, and it really is a BIG hack.  Off the top of my head,
what you do is post a command-i key down event to fake the finder into
getting info on the selection for you.  But before doing this, you have to
patch a bunch of traps.  Patching GetCatInfo will let you intercept file
information.  You also have to patch windowing traps to prevent the 'info'
window from being displayed.  I think I remember seeing that the 'info'
window either exists or is created offscreen and a MoveWindow call is made
to move it onscreen.  I think DiskDoubler just intercepts the MoveWindow
to prevent the window from being moved onscreen.  Since the window always
ends in "info", you will know which MoveWindow to prevent.  I think that
is the major part of it, but I would find my notes to verify this.

I have hacked around the Finder for other things, but in the process I have
seen it manipulating tables that contain info about onscreen icons.  I am
sure somewhere in that structure is information about whether the icon is
selected or not.  Another program worth hacking is an init that comes with
Now Utilities (or a least came with NU 2.0), that takes input from the
keyboard to make selections in the finder in a way similar to System 7.
If there is enough interest in making Finder selections, I am sure I could
hack it myself.

Hope this is of some help.

Dave Castell

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 17 Mar 92 18:38:04 GMT
Organization: The World Public Access UNIX, Brookline, MA

Dan -

Sharing code is great, I'm all for it! But...there are limits.

Do you think that Apple has to give away all of their secrets too?
What about Microsoft? Adobe? Claris? Ok then...why should the independent
freelance developer have to divulge their best secrets?

There are a LOT of things that I want to know how to do, and I've asked
companies and other programmers for help, and they've said (sometimes)
that they can't tell me. Simple.

<joe>










- --
<--------------------------------------------------->
 joe zobkiw                     [e-mail]
 mac.synthesis.MIDI.development.C.asm.communications
>---------------------------------------------------<

+++++++++++++++++++++++++++

From: [e-mail]
Date: 15 Mar 92 05:16:33 GMT
Organization: Campus Computing Sites, University of Michigan-Ann Arbor

In article <[e-mail]> [e-mail] (Dan Walkowski) writes:
>Has _anyone_ managed to figure out how to determine the Finder selection?
>
>Millions of frustrated Mac programmers (myself included) would praise you
>and probably even erect monuments if you would share the knowledge.
>
    To my knowledge only a small number of folks know how to do this,
and all of them (almost all) are compression software vendors who consider
this knowledge "proprietary" to their product line.

    That said, would people be willing to settle for an Extension and
background only app that was AEVT aware that could tell you the the
Finder Selection??   I've built such a combo, based on the technology
used in our Magic Menu product, but am curious just how useful it would
be to people.

    Would you be willing to pay for it?  Would developers be willing
to license it for inclusion in their own packages?  I know it would be
"REALLY NICE" for Aladdin to release this into the world for free, but I
have trouble convincing the "higher ups" of this.

    If you are a developer of a product that would be interested in
using this technology, please send me EMail about your usage.  Please
include info about whether the proudct is commercial or not.  If you feel
that we should release it free, express that too.  I will gather all the
messages together and make a "plea".

    Since I do not want my mailbox overflowing, ONLY respond if you
are a developer who would like to use this technology.

Thanks in advance for your messages and cooperation.

Leonard
- --
- -----------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 18 Mar 92 09:44:26 GMT
Organization: Apple DTS

In article <[e-mail]> [e-mail] (Dan Walkowski) writes:
>[e-mail] (Joe Zobkiw) writes:
>>Why should they give it away when people are willing to pay for it?
>Now what kind of attitude is that?

It's not quite as simple as either scenario would paint it.  Some
questions really should be answered but haven't yet been included in
System 7 documentation; for example, "How can I tell who sent me an
Apple event?"  (Check the address attribute.)  Some aren't documented
and aren't so kosher but are safe or at least simple enough, like "How
can I tell if I'm hidden?" (Check if a visible window has an empty
strucRgn.)

Getting the Finder selection goes way past that.  It's in the realm of
challenges which will take a while to figure out how to do, will take
longer -- maybe much longer -- to get working, and will probably break
anyway.  Almost daily, developers say, "I know it will break, I'll take
that risk."  In their eyes, such things are a competitive necessity.

IMHO, our primary obligation as Mac programmers isn't to help each
other, but rather to make the Mac better for users.  I'm not willing to
encourage others to write code that I expect will break because users
are the ones who pay the price when programs stop working.
Incompatible or fragile software doesn't make just one program look
bad, but rather gives people a sour taste for the whole Mac
environment.  If you're not concerned about the operating environment
outside of your own software, you very well might be better off
developing on a different computer, one with lower barriers for both
developers and users.

It is no secret that better support for a Finder suite of Apple events
is planned, and undoubtedly that would include the ability to find the
current selection.  In my judgement, users would be better served if
developers waited until then to develop software which depends on the
selected icons.  If you disagree, by all means, sit down with MacsBug
and have at it....

Good luck in your application development,

Grobbins            [e-mail]

Usual disclaimers apply, to wit: the above reflects my opinions
and not those of Apple Computer, Inc., a company which has graciously
provided me with this account.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Borg)
Organization: Camex Inc., Boston MA
Date: Mon, 23 Mar 1992 13:58:34 EST

In article <[e-mail]> [e-mail] (Joe Zobkiw) writes:
>Dan -
>
>I know of someone who has...a few people actually...but it is a well
>kept secret by the few who were able to figure it out :) Why should
>they give it away when people are willing to pay for it?
>

I have never done it, but I have an idea, and you all can have my idea
for free.

Do a "Get Info" on the selection.  The problem is that you would have
to patch Finder's environment to keep the user from having to deal
with that window.  Once you see the window coming up, watch for the
path string which is displayed there.

Problems: It would require an INIT and unless very carefully written,
it would be pretty certain to break next time Finder gets any real
changes--which is expected to be soon.  Also, if the user is editing
the name of the selection you will knock the interface out of that
mode.

Conclusion: Best wait until Apple gives us a real way to do it.

- --
Kent Borg                            internet: [e-mail]   AOL: kent borg
                                            H:[phone]  W:[phone]
"Eating healthy beef is not healthful, the steer will take offense at you
chewing on his flanks."      -me

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 27 Mar 92 22:46:19 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Dan Walkowski) writes:
>
> Has _anyone_ managed to figure out how to determine the Finder selection?
>
> Millions of frustrated Mac programmers (myself included) would praise you
> and probably even erect monuments if you would share the knowledge.

Someone has, and they will have to rewrite it every time the Finder changes.
Sounds like a lot of fun to me. ;)

The Finder will, in the nebulous future, support a request for its selection.
Until then it's you and Macsbug.  Happy hacking.

Jon

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 27 Mar 92 22:46:19 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Dan Walkowski) writes:
>
> Has _anyone_ managed to figure out how to determine the Finder selection?
>
> Millions of frustrated Mac programmers (myself included) would praise you
> and probably even erect monuments if you would share the knowledge.

Someone has, and they will have to rewrite it every time the Finder changes.
Sounds like a lot of fun to me. ;)

The Finder will, in the nebulous future, support a request for its selection.
Until then it's you and Macsbug.  Happy hacking.

Jon

---------------------------

From: [e-mail] (Tilman Reinhardt)
Subject: ML for Mac
Organization: Student Pool, CSD, University of Erlangen, Germany
Date: Tue, 17 Mar 1992 17:51:44 GMT


Does anybody know if there exists a version of ML for the Macintosh? I know that
there must be a version for MS-Dos. ML was developped at Edinburgh and is a language
with known semantics. Very suitable for prototyping and software verification.


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 30 Mar 92 02:59:36 GMT
Organization: MacDTS Mongols

In article <[e-mail]>,
[e-mail] (Tilman Reinhardt) writes:
>
>
> Does anybody know if there exists a version of ML for the Macintosh? I know
that
> there must be a version for MS-Dos. ML was developped at Edinburgh and is a
language
> with known semantics. Very suitable for prototyping and software verification.

..sorry for the delay, our nntp server is a couple of weeks behind
(again). The people behind SML are working on a Mac port as well,
check research.att.com now and then for the final port.

Cheers,
Kent Sandvik/DTS

---------------------------

Subject: Lost ETO
From: [e-mail]
Date: Thu, 19 Mar 1992 12:53:35 GMT
Organization: Actrix Information Exchange

My ETO #7 arrived today.  Great.  But I've never gotten #6 (in fact
living waaay out here in New Zealand I was expecting #6 when I
opened the box).

Anyone else the same?

What am I going to miss out on if #6 never turns up?  Just paper
docs, I guess, but for what?

- -- Bruce

- --
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 20 Mar 92 09:20:05 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>,
[e-mail] reports receiving ETO 7 without ETO 6.

Phone or fax APDA and tell them, Bruce. I've always had *excellent*
response from them on my complaints. I'm sure they'll send you out
an issue 6 if you ask them.

Lawrence
eagerly awaiting ETO 7.

+++++++++++++++++++++++++++

From: [e-mail] (Amanda Walker)
Date: 27 Mar 92 22:38:00 GMT
Organization: Visix Software Inc., Reston, VA

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> Phone or fax APDA and tell them, Bruce. I've always had *excellent*
> response from them on my complaints. I'm sure they'll send you out
> an issue 6 if you ask them.

I had to bug them about our ETO 6 (and I'm even in the USA :)).  Email &
voice messages didn't have much effect, but a (slightly acerbic) fax got
us our CD, apparently by return mail.


Amanda Walker                        [e-mail]
Project Leader, Multiplatform Software Development
Visix Software Inc.                     [phone]
- --
God is real unless declared integer.    -- Allen W. Sherzer ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Amanda Walker)
Date: 27 Mar 92 22:38:00 GMT
Organization: Visix Software Inc., Reston, VA

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> Phone or fax APDA and tell them, Bruce. I've always had *excellent*
> response from them on my complaints. I'm sure they'll send you out
> an issue 6 if you ask them.

I had to bug them about our ETO 6 (and I'm even in the USA :)).  Email &
voice messages didn't have much effect, but a (slightly acerbic) fax got
us our CD, apparently by return mail.


Amanda Walker                        [e-mail]
Project Leader, Multiplatform Software Development
Visix Software Inc.                     [phone]
- --
God is real unless declared integer.    -- Allen W. Sherzer ([e-mail])

---------------------------

From: [e-mail] (Brent)
Subject: GnuPlot on the mac --  UPDATE
Date: 20 Mar 92 19:53:47 GMT
Organization: Texas A&M Univ., Inc.


Hi all gnuplot fans!

This is just an update on my (slowed) progress on GnuPlot.

OK, at last report a few months ago, I had made the gnuplot 2.02 (version 2,
patchlevel 2) mac distribution available via anon ftp from tamsun.tamu.edu
in the pub/Macintosh directory.  At that time, gnuplot had a nasty bug
of not grokking the input command -- the tail end of it would get cut
off.  There were also some minor (not fatal) bugs present.

This morning I was able to fix the command bug and now have version 2.02
completely working.  I will make it available via anon ftp at the above site
sometime this weekend.

My next Direction:

Now that I have ported 2.02 and learned how the code is structured, I will
begin/continue work on version 3.0, which includes 3-D graphs.  Version 3.0
is very nice, and is just as quick as the previous versions.  It is also
larger.

What I am doing now is working on breaking away from Think C's console
routines (my workaround for graphics was a true hack) by writing my own
command window, where commands can be entered and output can be printed.
All drawing will be done in a separate window.

Anyway, feel free to send comments, suggestions, gripes, or notices of other
related work to me.  (BTW, I still have all the comments I gathered from
my 2.02 port.)

Also, when I do distribute the code, you must have
Think C 5.0 to recompile it (an executable is also provided).

- -Brent
- --
- ------------------------------------------------------------------------------
Brent P. Burton, N5VMG                                    Computer Sci/Physics
[e-mail]                                   Texas A&M University
- ------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Brent Burton)
Date: 21 Mar 92 06:15:18 GMT
Organization: Texas A&M Univ., Inc.

In my message earlier today, I wrote:
|
|This morning I was able to fix the command bug and now have version 2.02
|completely working.
|
|I will
|begin/continue work on version 3.0, which includes 3-D graphs.  Version 3.0
|is very nice, and is just as quick as the previous versions.  It is also
|larger.

This afternoon I ftp'd the version 3 patchlevel 1 distribution.  I spent
most of this evening sorting it out and comparing the code to version 2.02.
Luckily, all of the base code is identical and there was not much in the
way of me changing it.  Unfortunately, something in the code DID change
and my macintosh driver no longer works correctly.  I cannot find this
problem, but I'll keep looking for it.  The driver interfaces were not
modified for this release.  BTW, the compiled code is approximately 90k
larger (260k) than version 2 (170k).

Anyway, I just wanted to zap a quick note to let people know that version
3.0 is in the works, and as soon as I get it working AND get permission
to distribute the code, I'll let ya'll know.

As always, send comments to me.

- -Brent

- --
- ------------------------------------------------------------------------------
Brent P. Burton, N5VMG                                    Computer Sci/Physics
[e-mail]                                   Texas A&M University
- ------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Andy Edwards)
Date: 27 Mar 92 18:20:34 GMT
Organization: Harlequin Limited, Cambridge, England

Don't be a ThinkC klutz - there are MPW users on this planet.

+--: Andy Edwards :----------*=================*------------------------------+
| Macintosh fire fighter,    | Harlequin Ltd.  |      uucp: [e-mail]  |
| deity, PostScript language | Barrington Hall |     janet: [e-mail] |
| level 2 porter and PAP     | Barrington      | applelink: harlequin         |
| server clone originator.   | Cambridge       |     voice: 0223 872522       |
|                            | CB2 5RG         |            [phone]   |
|                            | England         |       fax: [phone]       |
+----------------------------*=================*------------------------------+

+++++++++++++++++++++++++++

From: [e-mail] (Brent)
Date: 28 Mar 92 22:40:38 GMT
Organization: Texas A&M Univ., Inc.

[e-mail] (Andy Edwards) writes:
|Don't be a ThinkC klutz - there are MPW users on this planet.

Well, I didn't think I was being a klutz about it...

On one of my posts I mentioned that I was writing my own "console" window
for the line-oriented I/O.  I have a basic shell of that working now and
this means that the (3.0) port of gnuplot will NOT depend on Think C's
console routines.

How's that for klutzmanship? ;-)

- -Brent
- --
- ------------------------------------------------------------------------------
Brent P. Burton, N5VMG                                    Computer Sci/Physics
[e-mail]                                   Texas A&M University
- ------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Andy Edwards)
Date: 27 Mar 92 18:20:34 GMT
Organization: Harlequin Limited, Cambridge, England

Don't be a ThinkC klutz - there are MPW users on this planet.

+--: Andy Edwards :----------*=================*------------------------------+
| Macintosh fire fighter,    | Harlequin Ltd.  |      uucp: [e-mail]  |
| deity, PostScript language | Barrington Hall |     janet: [e-mail] |
| level 2 porter and PAP     | Barrington      | applelink: harlequin         |
| server clone originator.   | Cambridge       |     voice: 0223 872522       |
|                            | CB2 5RG         |            [phone]   |
|                            | England         |       fax: [phone]       |
+----------------------------*=================*------------------------------+

+++++++++++++++++++++++++++

From: [e-mail] (Brent)
Date: 28 Mar 92 22:40:38 GMT
Organization: Texas A&M Univ., Inc.

[e-mail] (Andy Edwards) writes:
|Don't be a ThinkC klutz - there are MPW users on this planet.

Well, I didn't think I was being a klutz about it...

On one of my posts I mentioned that I was writing my own "console" window
for the line-oriented I/O.  I have a basic shell of that working now and
this means that the (3.0) port of gnuplot will NOT depend on Think C's
console routines.

How's that for klutzmanship? ;-)

- -Brent
- --
- ------------------------------------------------------------------------------
Brent P. Burton, N5VMG                                    Computer Sci/Physics
[e-mail]                                   Texas A&M University
- ------------------------------------------------------------------------------

---------------------------

From: [e-mail] (Roby Sherman)
Subject: WDEFs in System File:Do They Do Anything???
Date: 22 Mar 92 17:54:34 GMT
Organization: The Tao of Programming

In running system 6.0.8, I noticed 2 WDEF's in the system file. ID's 0 and
1. My question is, what do they do?

If I remove #0 or replace it with a modified WDEF resource, the computer
acts as if nothing has changed; Everything will still function as before.

If they are not used by the SYSTEM, what uses them?


               thanks,


                  Roby
- --
[e-mail]                    Roby Sherman

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Mon, 23 Mar 1992 14:15:20 GMT

In article <[e-mail]> [e-mail] (Roby Sherman) writes:
>In running system 6.0.8, I noticed 2 WDEF's in the system file. ID's 0 and
>1. My question is, what do they do?

Most macs have some version of the WDEF's in ROM. The system file versions are
for macs that don't have up-to-date versions (Is there any Mac with
movable-modal windows in ROM ?).

Matthias

- -----
Matthias Neeracher                                   [e-mail]
   "No, what he didn't like about heroes was that they were usually
    suicidally gloomy when sober and homicidally insane when drunk."
                          -- Terry Pratchett, _The Colour of Magic_

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 23 Mar 92 18:02:07 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.ch> [e-mail] (Matthias Ulrich Neeracher) writes:

   Most macs have some version of the WDEF's in ROM. The system file versions
   are for macs that don't have up-to-date versions (Is there any Mac with
   movable-modal windows in ROM ?).

Provbably the Quadras and PowerBooks...

- --
[e-mail]; Jon W{tte, the Diplomat - NOT!

+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 26 Mar 92 05:55:30 GMT
Organization: Dartmouth College, Hanover, NH


 Also note that Sys. 7 nas that nifty little (big?) color w-def in the
System, and probably a nifty Rov# resource to go with it.

Jeremiah (speaking of nifty, I don't have a nifty psedonym)

+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 26 Mar 92 05:58:04 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Jon W{tte) writes:

> Provbably the Quadras and PowerBooks...

and the LC2...

Jeremiah

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 26 Mar 92 23:36:09 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Roby Sherman) writes:
>
> In running system 6.0.8, I noticed 2 WDEF's in the system file. ID's 0 and
> 1. My question is, what do they do?
>
> If I remove #0 or replace it with a modified WDEF resource, the computer
> acts as if nothing has changed; Everything will still function as before.
>
> If they are not used by the SYSTEM, what uses them?

ID=0 is the standard window definition.  ID=1 is the rouned corner window.
The movable modal window is supported by the standard WDEF in System 7.
As far as I can tell, the WDEF is in every ROM and is replaced by every
System release.  So the one you should be running at all times is the one
in the System file.  If you were to replace ID=0, then all of your windows
should be drawn by your newly added WDEF.

- -----------------------------------------------------------------------
Jim Reekes, E.O.             |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 27 Mar 92 03:41:56 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Jim Reekes) writes:
>
> In article <[e-mail]>, [e-mail] (Roby Sherman) writes:
> >
> > In running system 6.0.8, I noticed 2 WDEF's in the system file. ID's 0 and
> > 1. My question is, what do they do?
> >
> > If I remove #0 or replace it with a modified WDEF resource, the computer
> > acts as if nothing has changed; Everything will still function as before.
> >
> > If they are not used by the SYSTEM, what uses them?
>
> ID=0 is the standard window definition.  ID=1 is the rouned corner window.
> The movable modal window is supported by the standard WDEF in System 7.
> As far as I can tell, the WDEF is in every ROM and is replaced by every
> System release.  So the one you should be running at all times is the one
> in the System file.  If you were to replace ID=0, then all of your windows
> should be drawn by your newly added WDEF.

Just to confirm what Jim is saying, I've replaced WDEF 0 in my IIci at
home and my IIfx at work, and the modified WDEF took effect each time.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 27 Mar 92 03:41:56 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Jim Reekes) writes:
>
> In article <[e-mail]>, [e-mail] (Roby Sherman) writes:
> >
> > In running system 6.0.8, I noticed 2 WDEF's in the system file. ID's 0 and
> > 1. My question is, what do they do?
> >
> > If I remove #0 or replace it with a modified WDEF resource, the computer
> > acts as if nothing has changed; Everything will still function as before.
> >
> > If they are not used by the SYSTEM, what uses them?
>
> ID=0 is the standard window definition.  ID=1 is the rouned corner window.
> The movable modal window is supported by the standard WDEF in System 7.
> As far as I can tell, the WDEF is in every ROM and is replaced by every
> System release.  So the one you should be running at all times is the one
> in the System file.  If you were to replace ID=0, then all of your windows
> should be drawn by your newly added WDEF.

Just to confirm what Jim is saying, I've replaced WDEF 0 in my IIci at
home and my IIfx at work, and the modified WDEF took effect each time.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

End of C.S.M.P. Digest
**********************